一開始我其實把資料處理想得很簡單：
CSV 放進 Cloud Storage，資料就算存好了。

這句話沒有錯，但問題是——存好了，然後呢？
如果我今天只是把 sample.csv 丟進 Bucket，確實可以保留下來，但我沒辦法很方便地問它：

• 哪一天營收最高？
• 某一段時間的銷售表現如何？
  我開始發現，資料「存在」和資料「可以被分析」，中間其實還隔了一層。

1. CSV 放進 Bucket，只完成了「保存」

這次我把 CSV 從 Cloud Storage 載入 BigQuery。
操作之前，我先理解了一件事情：
Cloud Storage 和 BigQuery 解決的問題其實不同。
Cloud Storage 比較像是把原始資料保存起來，而 BigQuery 則是讓資料進入分析環境。
CSV 放在 Bucket 裡，就像貨物先進入倉庫妥善保存；載入 BigQuery 後，才真正進入可盤點、查詢與分析的階段。

2. BigQuery 最讓我有感的地方：不用先管一台機器

以前操作 VM，我會先想到：

• 選什麼機型？
• 幾 GB RAM？
• 磁碟多大？
• 要不要開機？
• 用完要不要關？
  但 BigQuery 的使用方式完全不同。
  Google Cloud 把 BigQuery 定義為全代管、可擴展的分析資料倉儲，使用者可以直接透過 GoogleSQL 等方式進行分析，而不需要自己管理底層基礎設施。
  BigQuery 把「管理機器」這件事情藏起來，讓我把注意力放回資料本身。

3. CSV 的標題列

建立資料表時，我看到一個很容易忽略的設定：
要略過的標題列數：1
第一列通常是編號、日期、時間、數量...
如果沒有略過第一列，原本 50 筆資料可能變成 51 列，而且欄位型別也可能受到影響。

4. 把「驗收」放在資料處理流程裡

資料載入完成後，我檢查：
列數、日期、數量、總金額
把這幾個數字當成第一個重要驗收點。
因為最麻煩的是：
SQL 不一定會告訴我「你的資料有問題」。

它可能只是很正常地算出一個錯誤答案。

5. SQL 開始讓「資料」變成「問題的答案」

資料確認沒有問題後，開始試著從資料裡找答案。
一開始我只想知道哪一天賣得最好，但看到結果後，我馬上遇到另一個問題：
「賣得最好」到底代表什麼？
是當天訂單很多？
還是每筆訂單的金額特別高？
因此我沒有停在「總銷售額」這個數字，而是把同一批資料拆成「訂單數、總銷售額、平均訂單金額」三個角度來看。
這時候才發現，資料分析很少是一個問題得到一個答案就結束。第一個答案，往往只是下一個問題的起點。
這讓我開始把 BigQuery 理解成：
不是單純「放資料的地方」，而是資料進一步產生洞察的分析層。

結語

養成資料進來，先驗再用的習慣。
把資料處理拆成：
確認來源 → 載入 → 驗證 → 查詢 → 解讀
而不是：
載入 → 寫 SQL → 看結果
兩者最大的差別，就是中間多了一個「驗證」。
這個習慣未來資料量從 40 筆變成 4,000 萬筆之後，反而會更加重要。
因為資料越大，錯誤越不容易靠人工發現。
資料只有被正確驗證、整理並轉換成可以回答問題的形式，才真正開始產生價值。